Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ien/ien-35

Text File | 1988-12-01 | 33KB | 892 lines

INDRA Note 674
PSPWN **
IEN 35










              SATNET and the Provision of Transnet Service

                    P. T. Kirstein and C. J. Bennett










               ABSTRACT: This note discusses the  problem
               of  providing  service to ARPANET from the
               UK via SATNET after  the  existing  direct
               ARPANET   link   disappears.    A  general
               approach  is   outlined.    The   solution
               offered  attempts  to  make as much use of
               current hardware and software as possible.
               Areas  where  problems are anticipated, or
               where    insufficient    information    is
               available, are indicated.










                          INDRA Research Group
             Department of Statistics and Computer Science
                       University College London

SATNET and the Provision of Transnet Service                     Page  1













                                CONTENTS





1.  Introduction



2.  Overview

     2.1 Configuration
     2.2 Service Support
     2.3 Stages of Development



3.  Detailed Requirements

     3.1 UCL TIP
     3.2 UCL PDP9: Access to EPSS
     3.3 UCL PDP-11
     3.4 UCL PDP9: Access to X25
     3.5 UCL LSI-11
     3.6 Gateway LSI-11s
     3.7 TCP Service Gateway in the ARPANET



4.  Conclusions

SATNET and the Provision of Transnet Service                     Page  2



1.  Introduction

     With the transition of SATNET to a service role and  the  impending
demise  of  our  direct connection to the ARPANET, University College is
faced with the problem of how to provide access to the ARPANET  for  the
many  UK  users  who  have come to rely on it.  There are two aspects to
this problem.  Users who connect through our  site  in  London  must  be
given  terminal access to both ARPANET and EPSS (and possibly the future
public PSS, currently due  in  mid  1979).   Other  UK  users  accessing
ARPANET  through  EPSS and ARPANET users accessing EPSS hosts (including
the UCL service to Culham, RSRE etc) must be given adequate  support  at
the transport and terminal level to make this possible.

     Our solution to this must be based on our assessment of the current
state  of  techniques  for  implementing  transnet  services.   The most
significant development in this area  has  been  the  development  of  a
number  of network-independent protocols.  Providing network-independent
process-to-process  transport  service  has  had  the   most   attention
initially.   The  TCP is the result which is most familiar to members of
the ARPANET community.  Another network-independent  transport  protocol
is  the  INWG 96 proposal.  There has been a lot of discussion in Europe
on protocols for higher level  services  which  are  network-independent
(beyond  the  description  of  basic  transport facilities required) and
there are several proposals around for virtual terminal protocols,  none
of  which  has  yet met with general acceptance.  Recently the UK Higher
Level Protocol Group has published a proposal for a  network-independent
file  transfer  protocol,  available as INWG Protocol Note 86, which has
gained fairly wide approval in the UK and is  now  being  publicised  in
various  international  groups.   This  protocol is a development of the
file transfer protocol used on EPSS, and is being  implemented  on  many
sites  on that network, hence in this document it will be referred to as
the EPSS FTP.

     Ideally,  then,   we   would   like   to   implement   our   future
ARPANET/SATNET/EPSS  connection  within  this  context,  and assume that
connecting lines and machines and providing software  to  support  these
network  independent  protocols is a sufficient solution to the problem.
In practise, of course, such an attitude is utopian.   It  assumes  that
everyone  who  wants  internet  services  will adopt network-independent
protocols to do it,  and  they  will  be  perfectly  happy  to  do  this
themselves.   There  are  some very good practical reasons why this will
not happen.  Firstly, it means putting  a  great  deal  of  effort  into
developing  a  new  solution to a problem which has already been solved.
ARPANET users have for many years been using the ARPANET  file  transfer
protocol quite happily, and they are not going to implement a completely
different and incompatible one just to enable European users  to  access
their  files.   Secondly,  in order to achieve network-independence, the
protocols make the minimal assumptions possible about the nature of  the
underlying  network  services,  which means that they end up duplicating
many aspects of those services.  For this reason  it  is  unlikely,  for
instance,  that  TCP  or INWG 96 will be seen initially as an attractive
solution for providing transport services in an X25 environment  -  much

SATNET and the Provision of Transnet Service                     Page  3



of the emphasis of TCP is on providing end-to-end liaisons in a datagram
environment, which many people argue will involve a near duplication  of
features of the X25 virtual call, to take just one example.

     Therefore, we foresee  the  development  of  transnet  services  as
taking   place   at  a  limited  number  of  network  sites  within  the
concatenated networks, and it is unlikely that these  services  will  be
integrated  at  any  one  particular  site.   A  generalised view of the
transnet world under this scheme is given in Figure  1.   The  sites  at
which  the  network-independent  protocols  are  implemented  have  been
christened 'service gateways' as they are providing transnet access  for
particular  services.  Note that this concept is quite distinct from the
gateways  which  physically  connect  two  networks,  providing   packet
encapsulation,   fragmentation,   internet  routing  etc.   The  service
gateways need not stand in any particular physical relationship to  each
other  or  to  the  physical  gateways.   Clearly  there  will be strong
functional relations between the  physical  and  service  gateways,  and
there  is  a hierarchy of service gateways.  One major research interest
of the concept is in establishing just what these  functional  relations
are and how best they should be implemented.

     While the immediate aim of our network interconnection  project  is
simply  to  provide  communication  between  the  UK and ARPANET through
SATNET, the design chosen is one which will facilitate the provision  of
future  services across many networks using the service gateway concept.
Section 2 gives an overview of the proposed connection.  Section 3 gives
a more detailed survey of the software needed in each crucial machine to
support the service, relates this survey to  our  understanding  of  the
existing  state  of  the  hardware  and software for these machines, and
summarises the modifications to existing developments needed to  realise
the system.  Section 4 summarises our main conclusions.

SATNET and the Provision of Transnet Service                     Page  4





















































Figure 1 - The service gateway concept.

SATNET and the Provision of Transnet Service                     Page  5



2.  Overview.

2.1 Configuration

     The proposed future UCL configuration is given in  Figure  2.   The
principal points to note about this diagram are summarised below.

     i) The PDP-11, currently the gateway machine,  will  become  a
     transnet  access  host  on  the  TIP,  connected  via  the VDH
     interface currently connected to a PDP9, and probably  running
     under  a  standard  operating  system  such  as UNIX.  It will
     support terminal and file transfer access to and from  ARPANET
     via SATNET through TCP.

     ii) An alternate route  for  EPSS-ARPANET  traffic  will  pass
     through  the other PDP9 and the LSI-11 via the X25 connection.
     The PDP9 will lose its current VDH connection to the TIP.  The
     X25  connection  has  been so constructed that the LSI will be
     seen by users as an X25 host; EPSS sees the X25 interface as a
     process  on  the  PDP9.   This  LSI  will  also support TCP to
     provide access to the ARPANET.

     iii) The (physical) gateways to SATNET  will  be  replaced  by
     LSI-11s.   As  indicated,  the  UCL gateway will have two 1822
     interfaces and a VDH interface  whereas  the  gateway  on  the
     ARPANET  side  (presumably  the BBN gateway) may only have one
     1822 interface.   Special  hardware  for  the  LSI-11  may  be
     required  to  handle  50kb  on  the  VDH  line  across  a  DMA
     interface; this will (presumably!) be done by BBN.

     iv) A transport-level  service  gateway  supporting  TCP  will
     terminate  the  connection on the ARPANET side.  This may be a
     TENEX (or TOPS), or another PDP-11.  Further  terminal  access
     will  be  developed  via  ARPANET  Telnet;  support  for other
     services, such as transnet file transfer will also be provided
     at this point.


SATNET and the Provision of Transnet Service                     Page  6





















































Figure 2 - Proposed UCL Configuration

SATNET and the Provision of Transnet Service                     Page  7



2.2 Service Support


     The two major service requirements are the  provision  of  terminal
access  and  of  file transfer capability.  Terminal access requires the
mapping of various terminal protocols at the appropriate points,  rather
like the current SWITCH approach.  Mappings between the ARPANET standard
Telnet and the TCP-based  Telnet  will  be  required  in  the  transport
gateway  in ARPANET and in the PDP-11 at UCL.  The TCP-based Telnet will
map into the X25 VPT in the UCL LSI-11, and the  ARPA  Telnet  will  map
into  the  EPSS  VPT  in  the  PDP9  connected  to the TIP.  Much of the
complexity of this problem comes from linking up  two  connections  when
one  is being set up by the rather complex procedures of ICP.  It is not
clear  whether  TCP-Telnet  goes  through  a   similar   port-allocation
procedure.

     The situation with regard to FTP is not so clear.  The TCP group is
intending  to  implement  a  TCP-based  FTP,  but  this  is still in the
planning stages.  If this becomes available at the right time, then  for
service  purposes  we  would  perform analogous FTP mappings at the same
places.  This mapping can be done either on a  real-time  basis,  as  we
have  attempted to do for the EPSS and ARPANET FTPs on our PDP9, or on a
staged basis, with the file being stored on some mass-storage device and
forwarded  to the next stage only when it has all arrived.  Based on our
past experience, the staged solution is probably preferable when  it  is
possible.   The status of the TCP FTP is one of the major question which
needs to be followed up.  It may not  actually  be  necessary  to  do  a
detailed  mapping  of  FTPs  in  the TCP transport gateways, as both the
source and destination of the transfer will be using the  standard  ARPA
FTP.   It may only be necessary to map certain low-level features of the
FTPs, such as control and data sockets  being  mapped  into  TCP  ports.
This is an option which we should also investigate.

     If mappings of file transfers have to be done, it is desirable that
we  keep  these to a minimum, and it would be preferable to do them on a
large system, such as TENEX.  If TCP-based FTPs are to be used,  several
mappings  are  involved, none of them on systems of this type.  Since in
any case it seems that a TCP FTP  may  not  be  available  in  time,  an
alternative  strategy of implementing the EPSS File Transfer Protocol on
ARPANET could be adopted.  This protocol is specifically designed to  be
network and transport protocol independent, and so this is an attractive
proposition.  If  transnet  file  transfer  were  done  this  way,  this
protocol  would be implemented in the PDP-11 at UCL, interfacing to both
TCP and NCP, and at the  transport  gateway,  interfacing  to  TCP  (or,
indeed,  at some other site in ARPANET, in which case it would interface
to NCP).  In this case, the only FTP mapping required is at the site  in
ARPANET  which has the EPSS FTP installed.  The transport gateways (i.e.
the TCP site in ARPANET, the PDP-11 at UCL, the LSI-11 at UCL,  and  the
PDP9s at UCL) will then be supporting an end-to-end protocol between the
FTP service gateway in ARPANET and the destination site in EPSS  (or  at
UCL),   and   they   will   perform  the  classic  gateway  services  of
address-mapping, connection-establishment, flow-control, etc.

SATNET and the Provision of Transnet Service                     Page  8



2.3 Stages of Development

     The work needed for this development will  obviously  not  be  done
overnight.  We see the project taking place in three main stages.

     i) As much work as  possible  will  be  done  in  the  current
     configuration.   Development of software for the PDP-11 at UCL
     will probably be carried  out  on  a  PDP-11  in  the  ARPANET
     (exactly  which  one  is  to  be decided; see sections 3.3 and
     3.7).  The TCP/X25 LSI-11 will be developed as a terminal host
     on  a  local  host  port  on  the TIP (see section 3.5).  This
     situation will  continue  until  either  the  Norway  line  to
     ARPANET  disappears  or  LSI-11 gateways are ready.  We expect
     that the direct  connection  to  ARPANET  will  not  disappear
     before  the LSI gateways are ready, and this document is based
     on  that   assumption;   should   events   happen   otherwise,
     alternative  means  of  continuing development will have to be
     found.

     ii)  Once  the  LSI-gateways  are  ready  and  installed,  the
     configuration  of Figure 2 can be set up.  It is not necessary
     that both paths become operational at once, but we expect that
     the  TIP-based  path will be ready for use at that point, i.e.
     there will be an operational TCP-based terminal system on  the
     UCL  PDP-11.   The  TCP/X25 LSI-11-based path will be strictly
     for experimental development at this point, investigating  the
     nature  of  the  connections needed to support the appropriate
     services.   It  is  not  clear  whether  XNET  can   be   used
     satisfactorily  across  SATNET,  and  any development strategy
     based on XNET may have to be reconsidered at this point.

     iii) When the X25/TCP path is ready for service  use  it  will
     become  the  main service route between EPSS and ARPA.  Either
     now, or at some other  time,  the  PDP-11  could  be  directly
     connected  to  the  LSI-11  gateway,  and at some time it will
     probably support multiple terminals directly.  When all  these
     conditions are fulfilled, the TIP could be removed completely.
     No doubt this possibility will be looked at more closely  when
     the time comes.

SATNET and the Provision of Transnet Service                     Page  9



3.  Detailed Requirements


     This section describes the software needed in the various  machines
to support the service outlined above.  This is done machine by machine.
The proposals try to make the minimum changes needed to existing systems
or to current plans.  Attention is drawn to points on which we need more
information, or which we know or believe to be  incompletely  developed,
and also to areas in which problems are expected.

3.1 UCL TIP

     No functional changes are envisaged for this  machine,  which  will
continue  to  support  terminal  access as at present.  The major change
will be updating the routing tables to reflect  the  absolute  isolation
the  TIP  will  experience.   The major problem which BBN will encounter
will  be  in  providing  the  same  remote  maintenance  and  monitoring
facilities  it  has at present.  One possibility is to retain the direct
lines that ARPA currently maintains to the SIMPs (e.g.  the 9.6 kb  line
between  London  and  Goonhilly), as this is the simplest way to provide
direct access to our isolated TIP.   However,  this  is  a  problem  for
forces beyond our control.

3.2 UCL PDP9 Access to EPSS

     No major functional modifications to the existing SWITCH system are
expected  here  for providing terminal-level access.  Other services can
be set up as concatenated terminal streams.  If the EPSS  File  Transfer
Protocol  is  adopted  for  transnet service, this will be sufficient to
provide an adequate.  If not, then the current EPSS FTP/ARPA FTP mapping
will be used.  The resulting configuration is shown in Figure 3.

     There is some question as to how much work the full PDP9 system can
support  simultaneously.   If  serious  overloading  occurs, some of the
special systems supported (e.g.  the Culham link) may  be  removed  from
the  standard  system;  if even this is inadequate, then the position of
the FTP facilities may be reconsidered.

SATNET and the Provision of Transnet Service                     Page 10























Figure 3 - Terminal Access to EPSS via the PDP9

3.3 UCL PDP-11

     The PDP-11 is the  first  machine  considered  which  will  require
significant  effort  to bring up.  Much of the new software required has
either already been developed or is currently under development by  BBN,
notably TCP, TCP-Telnet, and these can be run under ELF, which we at UCL
have some experience with.  ELF has some disadvantages as  an  operating
system to support user services, however.  The principal one is that, to
the best of our knowledge, it does not support either  the  NCP  or  the
standard  ARPA  FTP.   This point should be checked.  The lack of an FTP
would be unimportant if the EPSS  File  Transfer  Protocol  is  adopted;
however the lack of adequate NCP facilities is critical.  Also, we would
prefer to use an operating  system  with  terminal  drivers  capable  of
handling  multiple  users,  as  we  ultimately  expect  to be using this
machine as a terminal concentrator to replace the  TIP.   The  main  new
item  which  has  to be tackled in this system is providing a connection
between NCP-based Telnet sockets and TCP-Telnet  ports.   As  a  gateway
between  two  transport  protocols  (TCP and NCP) this machine will also
have to handle the  usual  readdressing,  flow  control  and  reassembly
problems handled by gateways.

     The configuration under consideration is illustrated in  Figure  4.
The  existing  local  host interface will not be used, and connection to
the TIP will be via the VDH, as the two local host ports on the TIP  are
taken  up  by the PDP9 gateway to EPSS and the LSI-11 gateway to SATNET.
The looped nature of the traffic may create some  unusual  flow  control
problems  when there are heavy traffic rates.  For this reason, when the
file transfer facilities are developed for this machine, onward transfer
to  EPSS  will  be  done  in  a  staged  fashion,  with  the  file being
temporarily stored on the RK05 disc.

SATNET and the Provision of Transnet Service                     Page 11



     Since we have not been directly involved with the work,  one  major
question  on  which  we  lack  hard facts is the question of choosing an
appropriate operating system.  As we have indicated, ELF does  not  seem
to  be  suitable for a major service role of the kind implied here.  The
major PDP-11 operating systems that seem to be  suitable,  both  because
the   expertise   is   available  in  the  department  and  because  TCP
developments are taking place on them are UNIX and RSX-11M.  TCP version
2.5s  have been developed by BBN under UNIX and ELF; version 3 of TCP is
currently being developed by DTI under UNIX and by  CCA  under  RSX-11M.
The  only system under which a TCP-Telnet seems to be developing is ELF.
Further information must be obtained about these points.

     Two other points are relevant here.  The first is that it would  be
highly desirableable to be able to use the same operating system here as
we do on the remote transport gateway (see section 3.7) if this is to be
a  PDP-11; this would considerably speed up the development of the whole
system.   Secondly,  we  have  to  investigate  the  cross-net   loading
facilities.   The  great  advantage  of  ELF  is  the  fact  that  it is
specifically tailored to run with XNET.  With other operating systems we
will almost certainly require a special bootstrap to be able to use XNET
at all, and it is unlikely  that  we  will  be  able  to  use  its  full
facilities  even  then.   For debugging purposes this is not so serious,
but for cross-net loading it is vital.




















Figure 4 - PDP-11 Configuration

3.4 UCL PDP9 - Access to X25

     Here, the anticipated  course  is  that  the  current  system  will
develop  along  its  existing  lines,  with the complete excision of the
current ARPANET software.  For transnet communication an EPSS user  will
access  the  X25 port, which will also support incoming connections from
ARPANET.  The present SWITCH system running on this machine,  supporting

SATNET and the Provision of Transnet Service                     Page 12



the  EPSS  VPT and FTP, will be the standard system on the PDP9 which is
connected to the TIP.  Both Level 2 and Level 3  of  X25  are  currently
available,  and although it is designed basically as a DCE we anticipate
no great difficulty in turning it into a DTE if required.   This  point,
however,  requires  more detailed study.  Calls coming in from EPSS will
automatically be forwarded to the LSI-11 if no EPSS address is  included
in  the  data field.  In the reverse direction, calls being forwarded to
EPSS will require an EPSS address in the data field, but these  must  be
provided  by the LSI-11.  This scheme fits into the current context very
well, and we see no reason not to retain it.




















Figure 5 - UCL PDP9 - X25 Access

3.5 UCL LSI-11

     Essentially, this machine will consist of an X25 terminal and a TCP
terminal  connecting  an  HDLC  interface  on the one side to a BBN 1822
interface on the other through a number of mapping modules.   The  basic
structure is shown in Figure 6.  The X25 hardware for this configuration
has recently been completed, and the 1822  interface  is  nearly  ready.
The  software,  however,  is in a rather more uncertain state, and it is
expected that this terminal will remain an experimental  link  for  some
time.

     As with the PDP-11, it is not  clear  what  operating  system  this
machine  will  use,  although  the  alternatives  are  fewer: either the
current TCP terminal, available under  MOS,  is  altered  to  run  under
RSX-11,  or the current X25 terminal, available under RSX-11, is altered
to run under MOS.  RSX-11  will  support  development  in  a  high-level
language (RTL2), but it is doubtful whether this is advantageous, as the
generated code is large.  Also, whichever  system  used  will  initially
have  to  support  crossnet  loading  (and  possibly development) of the
TCP-terminal software.  This question is an unknown  for  both  systems,
and urgently needs resolution.

SATNET and the Provision of Transnet Service                     Page 13



     The TCP side of the terminal  is  based  on  the  packet-radio  TCP
terminal  developed  at SRI.  The major difference is the replacement of
the DSP, which is packet-radio dependent, by  an  XNCP-like  module  for
communication with the gateway.  This raises two problems.  The first is
the unorthodox nature of the 1822 connection, in that  neither  side  of
the  HOST/IMP interface supports what would normally be understood as an
IMP.  There is, however, a precedent for this situation, as  COMSAT  has
built a similarly non-standard connection between its 360 and its PDP-11
gateway, so we should be able to consult them for guidance for potential
problems.   Moreover,  1822  is  a  highly symmetric interface, so major
problems are not anticipated.  The second problem is  that  this  module
will initially only support a single TCP port, whereas there is a strong
requirement  for  supporting  several  ports  for  different   services.
However, creating a multiplexing 'XNCP' is not the whole solution to the
problem, as we will then be able to support several TCP connections only
if  they  go  to  different  hosts.   Unfortunately,  we need to support
several connections to one particular host (i.e.  the  remote  transport
gateway  in ARPANET - see section 3.7).  This will require modifications
to the TCP itself.

     Our current X25 is written in RTL2 or in assembler versions derived
from  it,  and is rather large in its RTL2 version.  The VPT is a larger
RTL2 program.  While the generated assembly code is believed not  to  be
highly  system  dependent, this aspect has not been analysed in detail -
the driver for the HDLC chip is a particularly important question  here.
On  the  face  of  it,  therefore, it would seem to be easier to put X25
under MOS than to put TCP (written in MACRO) under RSX-11 from the point
of  view  of aiding development.  The RTL2 code has been written so that
it can be run as both as X25 DTE  and  a  DCE,  and  one  problem  under
investigation  concerns  deciding when it should be one or the other.  A
study of the incorporation of  the  X25  software  into  MOS  should  be
undertaken very soon.

     Finally, there is the connection between the X25 side and  the  TCP
side.   At  this  stage,  it is not possible to say much more about this
than to state the functional requirements.  Terminal access will require
a  mapping between the X25-VPT and the TCP-Telnet; this will undoubtedly
be based on our experience with similar  problems  in  the  PDP9  SWITCH
systems.   File  transfer may also need to be mapped, and will certainly
require support  of  high-throughput  connections  on  both  sides;  the
evolution  of  suitable  strategies  to  match  the flow will have to be
evolved.  These modules will also have to solve the questions of forward
addressing and routing.  In the service gateway context, these functions
become more important than the mappings.

     The question of how this code is to be developed has still not been
satisfactorily  resolved.   There are two main options.  The first is to
develop it in our PDP-11, using  XNET  to  load  in  the  system.   This
requires  a MOS-based VDH driver for a DMA interface, which is currently
being written.  The second option is to load the LSI-11 directly,  using
one of our local host ports on the TIP.  This requires the completion of
the 1822 interface, which is proceeding rapidly.  Other options, such as
storing the software on floppy discs, are basically variants of these.

SATNET and the Provision of Transnet Service                     Page 14























Figure 6.  UCL LSI-11: TCP Access Configuration

3.6 Gateway LSI-11s

     No special role is envisaged  for  these  gateways,  as  end-to-end
transport  is  being  provided entirely by TCP at this point.  It is not
clear how far development on LSI-11 gateways has progressed, as  opposed
to  PDP-11 gateways; this is a question which must raised with BBN.  One
problem that may well  affect  the  schedule  is  that  our  preliminary
calculations  suggest  that access to the VDH line will have to be via a
DMA interface if high throughput is desired and the machine  is  not  to
spend  up  to  50%  of its time servicing interrupts from the interface.
Critical questions for  this  machine,  then,  are  the  development  of
MOS-drivers  for  DMA  VDH interfaces, and the ability of the gateway to
handle more than two nets - the 'nets' here being  SATNET,  the  TCP/NCP
PDP-11, and the TCP/X25 LSI-11.

     It is conceivable, if TCP develops concepts of selecting grades  of
service from local nets, that we may become interested in developing our
ideas in these gateways as well as the ones already discussed, but  this
does  not  seem  to be on the current schedule of TCP development and in
any case would have to be coordinated very closely with BBN.

SATNET and the Provision of Transnet Service                     Page 15























Figure 7 - UCL SATNET Gateway Configuration

3.7 TCP Service Gateway in the ARPANET

     Finally, a site in the ARPANET must be selected to provide the  far
end of the TCP pipeline.  The development needed here is very similar to
that discussed in section 3.3, and developing both  ends  simultaneously
on  PDP-11s  under the same operating system, as we did for GNOME, could
speed up the process considerably.   However,  the  system  support  and
system  resources  we  could  draw  on  are  likely to be limited unless
coupled with a TENEX.  Differences between the two sites will emerge  at
later  stages  in  the development.  These will be mainly connected with
addressing and routing problems: this machine will act as a service site
for  the whole US ARPANET, whereas the UCL PDP-11 will only service EPSS
traffic through the PDP9.

     The other alternative is to use a TENEX or TOPS-20 system for  this
end  of  the  connection,  as TCP and TCP-Telnet are both available, and
they have proved and extensive resources for such work.   However,  this
will  mean  developing  two  versions of the new software, and will also
involve experimenting with special versions of standard  software  (such
as  ARPA-Telnet, FTP, NCP) which may lead to organisational problems, as
these are machines supporting large  user  populations.   This  question
will again have to be gone into more deeply.

SATNET and the Provision of Transnet Service                     Page 16























Figure 8 - TCP Service Gateway Configuration

SATNET and the Provision of Transnet Service                     Page 17



4.  Conclusions


     In this note future ARPANET  service  is  considered  from  several
points  of  view.   Firstly, there is the problem of providing UCL users
with terminal access to ARPANET via SATNET.  Secondly, access has to  be
provided between EPSS and ARPANET for a variety of services.  Initially,
this will be of the terminal mapping type already in use, but the design
proposed has hooks for extension towards a more sophisticated concept of
supporting service gateways.  Where possible, the scheme  uses  existing
systems, or systems already under development.  Obviously, there will be
problems in modifying these to meet the new requirements, but the scheme
outlined  has  attempted  to  minimise  these,  and at the very least to
identify them.

     Integration  of  the  various  components  into  a  unified  system
requires  most  software  work  at  the  points  where various layers of
trsnsport protocol terminate and have to be connected to the next level.
The  two most critical points for providing a general transnet transport
service are in the TCP service gateway in ARPANET and the TCP/X25 LSI-11
at UCL.  A similar critical point occurs in the PDP-11 at UCL.  The PDP9
giving terminal access to EPSS from UCL is not critical as this  problem
has already been solved.  Again, a solution for the transport connection
between the EPSS Bridge and X25 is already in  existence  to  the  point
where  the LSI-11 will be seen as a host on EPSS when it is connected to
the PDP9.

     Specific areas  where  we  anticipate  difficulties  with  existing
software  are:  the  remote loading (and debugging) of non-ELF operating
systems for the PDP-11; the  choice  of  an  operating  system  for  the
LSI-11;  the  nonstandard  nature  of the 1822 interface connecting this
machine to the gateway LSI-11; the use of XNET across  SATNET;  and  the
provision of a DMA VDH interface on the gateway LSI-11s, to connect them
to SATNET.  Areas on which we  need  further  information  include:  the
status  of  TCP  and  TCP-Telnet under various standard PDP-11 operating
systems; the current status (or even the existence!) of the TCP-FTP; the
current status of LSI-11 gateways; and information that we can get about
activities such as the non-standard 1822  connections  which  have  been
undertaken by other groups.

     In short, the components  required  to  connect  UCL  and  EPSS  to
ARPANET  via  SATNET  are  on  the  whole either already in existence or
already under development.  The new work is in sticking them together in
such a way as to provide adequate transnet service.